Not applicable.
This invention relates to electronic programmable controllers for operating industrial equipment, and more particularly, to a programming language used to develop control programs performed by industrial controllers to control industrial equipment.
Programmable controllers are well-known systems for operating industrial equipment, such as assembly lines and machine tools, in accordance with a stored program. In these controllers, a stored program is executed to examine the condition of specific sensing devices on the controlled equipment, and to energize or de-energize selected operating devices on that equipment contingent upon the status of one or more of the examined sensing devices. The program not only manipulates single-bit input and output data representing the state of the sensing and operating devices, but also performs arithmetic operations, timing and counting functions, and more complex processing operations.
One industry which extensively uses programmable controllers is the automotive industry. In the automotive industry, various automotive parts are conveyed along machine lines consisting of many consecutive workstations. Most workstations include at least one tool which performs some function to alter the characteristics of work pieces as they are delivered to the station. For example, an unfinished cast engine block that requires a plurality of holes, bores, and threads, as well as other metal-removing procedures, may be provided at the beginning of a machine line that produces finished engine blocks. The machine line may consist of any number of different stations, each station performing a different procedure on the unfinished block. An indexer in the form of a transfer bar can be arranged to move each block from one station to the next following a completed process. Typically, at each station the block would be clamped prior to any metal-removing operation.
In this type of system, a programmable controller would receive inputs from all of the various tools at all of the workstations and would provide activating output signals to synchronize machine operation. During metal-removing periods with the transfer bar out of the way, all of the tools would perform their functions. In between metal-removing periods during transfer periods, the tools would be parked, the clamps unclamped, and the transfer bar would advance workpieces from one station to the next.
Industrial controllers are frequently programmed in xe2x80x9crelay ladderxe2x80x9d language (RLL) where instructions are represented graphically by xe2x80x9ccontactsxe2x80x9d and xe2x80x9ccoilsxe2x80x9d of virtual relays connected and arranged in ladder-like rungs across power rails. RLL, with its input contacts and output coils, reflects the emphasis in industrial control on the processing of large amounts of input and output data.
RLL also reflects the fact that most industrial control is xe2x80x9creal timexe2x80x9d; that is, an ideal industrial controller behaves as if it were actually composed of multiple relays connected in parallel rungs to provide outputs in essentially instantaneous response to changing inputs. Present industrial controllers do not, in fact, employ separate parallel relay-like structures, but instead simulate the parallel operation of the relays by means of a conventional Von Neumann-type computer processor which executes instructions one at a time, sequentially. The practical appearance of parallel operation is obtained by employing extremely fast processors in the execution of the sequential control program.
As each rung is executed, inputs represented by the contacts are read from memory (as obtained from inputs from the controlled process or the previous evaluation of coils of other rungs). These inputs are evaluated according to the logic reflected in the connection of the contacts into one or more branches within the rungs. Contacts in series across a rung represent boolean AND logic whereas contacts in different branches and thus in parallel across the rung represent boolean OR logic.
Typically a single output coil at the end of each rung is set or reset and, based on the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a bit (which ultimately becomes an output to the industrial process or to another RLL rung).
Once a given rung is evaluated, the next rung is evaluated and so forth, In the simplest form of RLL programming, there are no jumps, i.e. all rungs are evaluated in a cycle or xe2x80x9cscanxe2x80x9d through the rungs. This is in contrast to conventional computer programming, where branch and jump instructions cause later instructions or groups of instructions to be skipped, depending on the outcome of a test associated with those branch or jump instructions.
While RLL is well-suited for controlling industrial processes like those in the automotive industry, RLL programming is not an intuitive process and, therefore, requires highly-skilled programmers. Where hundreds of machine tool movements must be precisely synchronized to provide a machining process, programming in RLL is extremely time-consuming. The time and relative skill associated with RLL programming together account for an appreciable percentage of overall costs associated with a control system. In addition, the final step in RLL programming is typically a lengthy debugging and reworking step which further adds to overall system costs.
One way to streamline any type of programming is to provide predefined language modules, expressed in a language such as RLL, which can be used repetitively each time a specific function is required. Because of the similar types of tools and movements associated with different machine-line stations, industrial control would appear to be an ideal industry for such language modules.
The predefined logic module approach works quite well for certain applications, like small parts-material handling or simple machining. The reason for this is that the RLL logic required for these applications tends to be very simple. In small parts material handling applications the 1/0 count is low and the interfaces between modules are minimal. In fact, the mechanisms are often independent units, decoupled from neighboring mechanisms by part buffers such that no signals are required to be exchanged between modules. These xe2x80x9cloosely coupledxe2x80x9d systems lend themselves to xe2x80x9ccut and pastexe2x80x9d programming solutions.
But the predefined, fixed logic module approach does not work well for other applications, for example metal-removing applications. There are two main reasons for this. First, there can be considerable variation in how components, such as sensors and actuators, combine to produce even simple mechanisms. Second, processes like metal removing normally require tightly controlled interaction between many individual mechanisms. The interaction is controlled by exchanging signals, called interlocks, between the control logic modules of the individual mechanisms. The application of specific interlocks depends on knowledge of the process and the overall control strategy, information not generally needed, or knowable, when the control logic for each mechanism is defined.
For example, a drill is a typical metal-removing tool used in the automotive industry. In this example an ideal drill is mounted on a carriage that rides along a rail between two separate limiting positions on a linear axis, an advanced position and a returned position. Two limit switches, referred to herein as returned and advanced LSs, are positioned below the carriage and, when tripped, signal that the drill is in the returned and advanced positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the advanced and returned positions are reached, respectively. In the ideal case, both LSs may be assumed to be wired in the same xe2x80x9cnormally openedxe2x80x9d manner, so that electrically speaking they are open when released and closed when triggered. In this ideal case, where the physical characteristics of the switches are limited, a single RLL logic rung can determine when the drill is in the returned position and another rung can determine when the drill is in the advanced position.
Unfortunately, in reality, there are electrically two types of LSs, one LS type being wired normally opened and the other type wired normally closed. Furthermore, any LS can be mechanically installed in a tripped when activated configuration, or a released-when-activated configuration. All combinations of these types are used for various types of applications. Thus, application requirements may demand control logic capable of handling any configuration of LS types.
Simple mathematics demonstrates that with two different electrical types of LSs and two mechanical configurations, there are sixteen possible configurations of a two-position linear slide. Consider the language modules required to implement position logic for all these configurations. To accommodate all sixteen switch configurations, there could be sixteen different language modules, each containing fixed RLL logic, and each named for the case it could handle. In this case, there would be duplicate logic under different names. Alternatively, four unique language modules could be provided, but then the user would have difficulty identifying which of the sixteen physical configurations could be handled by which of the four modules.
Clearly, even for a simple drill mounted on a two position linear slide, application variables make it difficult to provide a workable library of fixed language modules. Adding more switches to the linear slide only increases, to an unmanageable level, the number of language modules required in the library.
Moreover, the contents of a complete language module for a drill must also consider other variables: including the number and type of actuators required; the type of spindle, if any; whether or not a bushing plate is required; what type of conveyor is used; whether or not the drill will include an operator panel to enable local control; and, if an operator panel is included, what type of controls (i.e. buttons, switches and indicator lights) are required; just to name a few. Each tool variable increases the required number of unique RLL modules by more than a factor of two, which makes it difficult at best to provide an RLL library module for each possible drill configuration.
Taking into account the large number of different possible machine-line tools, each tool having its own set of variables, the task of providing an all-encompassing library of fixed language modules becomes impractical. Even if such a library could be fashioned, the task of choosing the correct module to control a given tool would probably be more difficult than programming the required RLL logic from scratch.
For these reasons, although attempts have been made at providing comprehensive libraries of fixed language modules, none has proven particularly successful and much RLL programming is done from scratch.
Therefore, in order to reduce programming time and associated costs, it would be advantageous to have a more flexible means of specifying control logic that provides for the specification of truly reusable sections of RLL or other control logic. Furthermore, it would be advantageous if a library of reusable modules enabled industrial engineers less-skilled in programming to provide complete control logic programs and to reduce required debugging time. Finally, it would be advantageous if such a library of reusable modules could be accessed using a programming apparatus such as a personal computer, or the like, to further minimize programming time and cost.
The present invention includes a new language called template language, which allows the specification of truly reusable units of control logic, called templates, such that a library of these templates, when combined with parameters describing a specific application, results in relay-ladder or other control logic with desired structure and behavior. A control logic program for controlling an entire machine line can be developed by selecting templates specifically designed to control different machine aspects and parameterizing those templates for specific applications.
It has been recognized that a machine line can be broken down into different control-tasks to form a hierarchy of machine control, each successive hierarchical level being more detailed than the previous level. Herein the term xe2x80x9ccontrol-taskxe2x80x9d is used to refer to various machine aspects generally including separate machine components, component characteristics, movements, and operational states.
Each control-task can be characterized by various aspects that can be divided into two different groups. A first group includes aspects that are universally true for every control-task of a specific type. For example, for safety purposes every machine must include at least one control panel having means for turning the machine ON and OFF. Therefore, a universal machine requirement or aspect is an ON-OFF means.
A second group includes control-task aspects that are distinct to specific instances of a control-task type. For example, one application may require that a control panel also include specific manual controls whereas another application may. not require manual controls.
The template language provides a separate template for each specific control-task. Each template may contain elements of two different types of information.
First, each template may include a set of truly reusable control logic statements, for example RLL rungs, required to control a specific control-task type. In the example above, where every machine line requires an ON-OFF means, a machine template will either directly or indirectly include reusable rungs of RLL logic for ON-OFF control. Typically, because reusable logic will be required for all control-tasks of a specific type, control logic produced in templates is not meant to be altered (except in the case where an end user wishes to customize templates for a specific industry).
Second, each template may include elements that indicate instances of other templates (an instance of a template being referred to hereinafter as a module) that may contribute additional logic for distinct aspects of the designating module. In this way, the designating template provides for variation in how the associated control-task may be configured. The designating and designated modules are usually considered to have a parent/child relationship.
Using the inventive templates, a user can construct a complete xe2x80x9cmachine treexe2x80x9d that represents an industrial process to be controlled. At the distal ends of a machine tree, a user uses a more detailed set of templates to precisely model the control-task of the application. These more detailed modules, like the modules discussed above, include reusable logic and references to other modules required to completely provide control logic for every control-task associated with a machine.
Once an entire template-based machine representation has been constructed, user can then work through the machine tree and effectively compile a complete control program by substituting child modules for specifications in parent modules until all that remains is control logic.
Hence, the template language includes a first set of statements that can be used to construct a template-based machine tree using a relatively small template set, and a second set of statements (e.g., RLL language forms plus extensions to those forms) that, when compiled, provides a complete RLL logic program.
One objective of the present invention is to reduce the amount of time required to produce control programs. By using reusable control logic, programming time can be reduced to a fraction of the time required to program from scratch.
Another objective is to reduce programming time while still allowing a user to customize control logic for any required application. In the present invention, while reusable RLL logic is provided, the user can customize logic where required by building a machine tree tailored to job-specific parameters of an application. In effect, where options are required, a greater number of templates are provided which can be used as small building blocks to provide required logic.
The present invention also provides programming flexibility by breaking down a machine line past the tool level to a more basic control-task level including movements, positions, and component characteristics. Whereas on the tool level, literally thousands of separate library modules would be required to provide reusable logic for all tool configurations (because all control-tasks can be described using a small number of modules based on the control-tasks) flexibility can be maintained without a large module library.
Yet another objective is to reduce the amount of programming training required to provide a complete control program. The present templates make programming largely unnecessary. A programmer simply constructs a machine tree which resembles a machine-line process and then plugs child modules into the tree to complete the programming process.
Other objectives are to reduce debugging time and costs associated with control programming. Debugging time is reduced because, when a programmer is done programming, the basic form of the machine tree is reflected in the resulting control program. Therefore, when a bug is detected in a certain portion of a machining process, a programmer can simply go to the area of a machine tree corresponding to the flawed process and examine that area for problems. Because programming and debugging times are reduced, and because relatively unskilled programmers can produce control programs using the present invention, overall programming and control system costs are minimized.
In addition, a programming apparatus editor is provided that allows a user to easily construct a template-based tree, thus further reducing programming costs and time.
Finally, another objective of the invention is to provide the underlying control language form, RLL, with extensions that make the template language extremely flexible for accommodating job-specific requirements, allowing the user to create truly reusable logic. Specifically, the control language extensions make it possible to preprogram, in a template set, all required interactions between modules, prior to knowing application module specifications, and to accommodate variable numbers of modules. In addition, the extensions include compile-time instructions that can indicate when certain control statements logic should be included in a program as a function of various job-specific parameters.